-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Resilience fixes for the Ingress controller #652
Resilience fixes for the Ingress controller #652
Conversation
6b0366c
to
fc525de
Compare
// If this controller is scheduled on a node without compute/rw | ||
// it won't be allowed to list backends. We can assume that the | ||
// user has no need for Ingress in this case. If they grant | ||
// permissions to the node they will have to restart the controller |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FMOK, does user have to restart controller? why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I loop around here continuously re-creating the client till ListBackendServices succeedes, the liveness probe will fail at some point and cause a crashloop. I want to not crash if scheduled on a r/o node.
Another way to handle this is to keep re-creating the client object in the liveness probe, and if it suddenly starts succeeding ListbackendServices calls, somehow re-notify everyone I've given the old client to refresh their clients. Didn't think this level of effort was worth it, since we can just doc that the controller needs permissions and leave it at that.
fc525de
to
3db3247
Compare
@freehan PTAL |
LGTM, except the formatting nit... |
3db3247
to
bbb448a
Compare
Fixed nit, inheriting lgtm and merging on green |
Reasoning for each commit: